Project archive and restore from one database to another

I am trying to archive project/modules from one database A to another database B with all the rights and access of users and groups to be restored.
Is it possible that i can restore the same access and inheritance of users and groups from one database to another. As the project archive and restore can be done without any issue but the problem comes for restoring the access for users.

Can anyone please guide what approach can be followed so that access right for users and groups on the project/ modules are safe during archiving and restoring from one database to another?
SystemAdmin - Wed Oct 17 00:52:29 EDT 2012

Re: Project archive and restore from one database to another
SystemAdmin - Wed Oct 17 01:21:28 EDT 2012

The reason why all of the access rights have been defaulted back to inherited is because each individual user login account is assigned a unique database ID that is specific to that database.

When you restore on another database, the user unique ID's will most likely be different or non existent and will not match up, so DOORS avoids this contention and just defaults access rights back to inherited.

Even if users have login accounts on both databases, it is most improbable that they will have been assigned the same unique ID.

DOORS does actually record all of the access rights with the Archive, but this is only useful if the Archive is restored back onto the same database.

No easy fix as far as I know other than replicating manually, but lets wait and see if any others on this have a practical solution up their sleeves.

Paul Miller,
Melbourne, Australia

Re: Project archive and restore from one database to another
SystemAdmin - Wed Oct 17 01:32:09 EDT 2012

SystemAdmin - Wed Oct 17 01:21:28 EDT 2012
The reason why all of the access rights have been defaulted back to inherited is because each individual user login account is assigned a unique database ID that is specific to that database.

When you restore on another database, the user unique ID's will most likely be different or non existent and will not match up, so DOORS avoids this contention and just defaults access rights back to inherited.

Even if users have login accounts on both databases, it is most improbable that they will have been assigned the same unique ID.

DOORS does actually record all of the access rights with the Archive, but this is only useful if the Archive is restored back onto the same database.

No easy fix as far as I know other than replicating manually, but lets wait and see if any others on this have a practical solution up their sleeves.

Paul Miller,
Melbourne, Australia

Thanks Paul for the quick reply.

I understand that every user have different id specific to the database.But is there any way possible that if we have script that will give the details of all user access on the project/module and the same detail can be exported from database A and then imported into other database B.
once we import the list, again a script can be run which we will restore the same access as in database A.

Just trying to suggest, please correct me if i am wrong.

Re: Project archive and restore from one database to another
llandale - Wed Oct 17 10:51:36 EDT 2012

You have a big problem if you want an individual project to have identical accesses. You'll need to dump the current accesses to some file with a DXL, and use a different DXL to read that file and apply it to the recently restored project.

However:
[1] If you want the 2nd database to simply be some form of read-only replica of the 1st, then you can move the entire database file structure from the Home and completely replace the Away; perhaps weekly.

[2] If you want the 2nd database to have the same users as the first but retain its own active Projects, you can
  1. Initially, copy the database hierarchy of the Home and create the Away with it. Thus, the database IDs would be the same. Presumably then delete and purge most of the Projects in the Away.
  2. Archive the User info from the Home and restore it in the Away, perhaps weekly. Do NOT create any new users in the Away database and certainly don't bother giving any new Away users accesses. This is a very dangerous step.
  3. Archive and restore the Project. The "restore" should believe it is being restored in the original database (since the IDs are the same) and thus preserve the accesses.

I've never done [2] and would be interested in hearing if it works.

-Louie

Re: Project archive and restore from one database to another
SystemAdmin - Wed Oct 17 11:26:17 EDT 2012

llandale - Wed Oct 17 10:51:36 EDT 2012
You have a big problem if you want an individual project to have identical accesses. You'll need to dump the current accesses to some file with a DXL, and use a different DXL to read that file and apply it to the recently restored project.

However:
[1] If you want the 2nd database to simply be some form of read-only replica of the 1st, then you can move the entire database file structure from the Home and completely replace the Away; perhaps weekly.

[2] If you want the 2nd database to have the same users as the first but retain its own active Projects, you can

  1. Initially, copy the database hierarchy of the Home and create the Away with it. Thus, the database IDs would be the same. Presumably then delete and purge most of the Projects in the Away.
  2. Archive the User info from the Home and restore it in the Away, perhaps weekly. Do NOT create any new users in the Away database and certainly don't bother giving any new Away users accesses. This is a very dangerous step.
  3. Archive and restore the Project. The "restore" should believe it is being restored in the original database (since the IDs are the same) and thus preserve the accesses.

I've never done [2] and would be interested in hearing if it works.

-Louie

The Administrator account can archive and restore users and groups. If the same user/group IDs are wanted between the two databases, doing the archive and restore will set them to be the same. The restore of the archived project will then retain all the same permissions as the original.

Re: Project archive and restore from one database to another
SystemAdmin - Thu Oct 18 08:25:08 EDT 2012

llandale - Wed Oct 17 10:51:36 EDT 2012
You have a big problem if you want an individual project to have identical accesses. You'll need to dump the current accesses to some file with a DXL, and use a different DXL to read that file and apply it to the recently restored project.

However:
[1] If you want the 2nd database to simply be some form of read-only replica of the 1st, then you can move the entire database file structure from the Home and completely replace the Away; perhaps weekly.

[2] If you want the 2nd database to have the same users as the first but retain its own active Projects, you can

  1. Initially, copy the database hierarchy of the Home and create the Away with it. Thus, the database IDs would be the same. Presumably then delete and purge most of the Projects in the Away.
  2. Archive the User info from the Home and restore it in the Away, perhaps weekly. Do NOT create any new users in the Away database and certainly don't bother giving any new Away users accesses. This is a very dangerous step.
  3. Archive and restore the Project. The "restore" should believe it is being restored in the original database (since the IDs are the same) and thus preserve the accesses.

I've never done [2] and would be interested in hearing if it works.

-Louie

Yes, Louie. You are correct its a big problem. I am not sure about the outcome, just trying..

As the approach mentioned in option "You'll need to dump the current accesses to some file with a DXL, and use a different DXL to read that file and apply it to the recently restored project."

In this method if we are using the DXL then will it possible to replicate the access rights on the database B which has different data as compared to database A. Here,I just want to restore one module/project on database B but with full access to users/groups as in database A.
Its possible to get the access on the archived project through a DXL script but the problem occurs when the rights have to replicated on database B,if we have a different set of users there, then do we need to create the new users for restored project manually or can it be done through script?

Re: Project archive and restore from one database to another
llandale - Thu Oct 18 15:25:36 EDT 2012

SystemAdmin - Thu Oct 18 08:25:08 EDT 2012
Yes, Louie. You are correct its a big problem. I am not sure about the outcome, just trying..

As the approach mentioned in option "You'll need to dump the current accesses to some file with a DXL, and use a different DXL to read that file and apply it to the recently restored project."

In this method if we are using the DXL then will it possible to replicate the access rights on the database B which has different data as compared to database A. Here,I just want to restore one module/project on database B but with full access to users/groups as in database A.
Its possible to get the access on the archived project through a DXL script but the problem occurs when the rights have to replicated on database B,if we have a different set of users there, then do we need to create the new users for restored project manually or can it be done through script?

A big problem is that access rights are based on the User UniqueID and not the user name. If you provide "Joe" RMCDA and "Jane" R access then really user 10f4 (Joe's unique ID) has RMCDA. If you rename user Jane to Temp, Joe to Jane, and Temp to Joe, then Jane will have RMCDA since that is still user 10f4.

The restore-in-same-database mechanics for preserving accesses takes advantage of that; user 10f4 has RMCDA to a module it will also have RMCDA to the corresponding restored module. But that only works since it is the same user; "Joe" in some other database will have a different ID such as "4e".

So, the custom solution must export access records in name/access text format e.g. "NameModule", "Joe", and "RMCDA", and another script reads that and applies that to the restored database. problem of course if "Joe" doesn't exist or if "Joe" is the name of some other user. Thus, the user database of both databases need to be coordinated in some way which leads to my two alternative possibilities; one database has the source of the users and the other regularly gets a copy.

I don't recall anybody posting such scripts here.

-Louie